In RFC 3261, the Internet Engineering Task Force (IETF) described Session Internet Protocol (SIP), an application-layer signaling protocol for creating, modifying, and terminating sessions with one or more participants.
SIP can be and is used to setup a series of related instant messages between two or more parties which are part of a “message session”, that is, a conversational exchange of messages with a definite beginning and end. A paging session offers several advantages over stand-alone “page-mode” or “large message mode” messaging including higher security as well as the “presence” indicator to show the status of the recipient as well as the willingness of the recipient to receive a message prior to sending of the message.
This is in contrast to individual messages each sent independently. Using an extension to the SIP protocol, SIP can also be used to send standalone Messages via the SIP message MESSAGE as documented in IETF RFC 3428.
Messaging schemes that track only individual messages can be described as either “page-mode” messaging or “large message mode” messaging, whereas messaging that is part of a “session” with a definite start and end is called “session-mode” messaging.
One common session based protocol which uses SIP to setup the session, is known as Message Session Relay Protocol (MSRP).
In spite of the advantages of session based messaging, there are classes of instant messages which are not always easily handled within the session, especially in a mobile client environment. This includes Instant Message Disposition Notification (IMDN) messages.
Disposition notifications may, for example, include a message delivery notification, a display notification (also known as “read report”), a deletion notification of the message, or the notification that the recipient has refused to provide a message disposition to the sender of the origin al message.
In a mobile environment, minutes, hours or days may pass between the original sending of the message and the time when the message disposition is known for every recipient. This could be due to temporary or permanently leaving a radio coverage area, power cycle of one of the client devices, interruption of service due to insufficient funds or other reasons. After this hiatus, one or more of the message recipients are very likely no longer in the original session. Current art supports stand-alone page-mode disposition notifications in response to stand-alone page-mode messages and current art also supports disposition notification while all parties are still in a paging session. However, the current art does not address sending a disposition notification to a session based messaging client once the original session has terminated to one of the clients. This represents a serious functional loss to the end user for a situation that is common in a mobile environment.
Reestablishment of the same session merely to send the disposition notification is not supported. This method would also add the inefficiency of session setup and teardown even if this method was supported by the known art.
A related problem is that the message ID used in the disposition notification may not be sufficient to route to the proper server for an operator that has multiple instant message servers (and thus several sets of message IDs) or for an operator that may reuse message ID's over a period of time between the message being sent and the disposition notification.
What is needed is a way to send a disposition notification in response to a message sent in a message session, where the disposition can be sent after a message session has ended. What is also needed is a method way to associate the disposition message with the original server and original session. These are the problems solved by this invention.